Bug Proofing Visual Basic: A Guide to Error Handling and Prevention
(Publisher: John Wiley & Sons, Inc.)
Author(s): Rod Stephens
ISBN: 0471323519
Publication Date: 11/01/98

If a routine has any special limitations, like requiring the upper and lower bounds to be positive, use Debug.Assert or Stop statements to verify those conditions. The following code uses the Mod operator to map a value into an array. For the Mod operation to work correctly, the array’s lower bound must be 0 and its upper bound must be at least 1. This code checks those conditions. It also watches for other potential bugs by verifying that the upper bound is at most 99 and that the value to be mapped is between 0 and 1000.

‘ Map a value into an array.
‘ Requirements:
‘       LBound(arr) = 0
‘       UBound(arr) >= 1
‘ Restrictions:
‘       UBound(arr) <= 99
‘       0 <= value <= 1000
Private Sub MapValueToArray(arr() As Integer, value As Integer)
Dim u_bound As Integer
Dim l_bound As Integer
Dim num_entries As Integer

    ‘ Get the array’s bounds and verify that
    ‘ the array has been allocated.
    On Error GoTo UnAllocated
    u_bound = UBound(arr)
    l_bound = LBound(arr)
    On Error GoTo 0    ‘ Resume normal error handling.

    ‘ Validate the parameters.

    Debug.Assert (value >= 0) And (value <= 1000)
    Debug.Assert l_bound = 0
    Debug.Assert (u_bound >= 1) And (u_bound <= 99)

    ‘Map the item into the array.

    num_entries = u_bound + 1
    arr(value Mod num_entries) = value
    Exit Sub

UnAllocated:
    If Err.Number = 9 Then

     ‘ The array has not been allocated.
        Err.Raise err_UNALLOCATED_ARRAY, _
            “MyProgram.MapValueToArray”, _
            “Parameter ”“arr”“ has not been allocated with ReDim”
    Else

    ‘ Reraise the unknown error.
           Err.Raise Err.Number, _
            Err.Source, Err.Description, _
            Err.HelpFile, Err.HelpContext
    End If
End Sub

Use LBound and UBound to make your subroutines robust and easy to modify. Verify requirements and restrictions on bounds to catch potential bugs.

Validate Data Structures

An application should include a series of subroutines that test its supporting data and data structures for errors. These routines can validate data in arrays, check for invalid program options, examine database entries, read and verify the contents of data files, check system registry values, and so forth.

For example, suppose the program displays a corporate organization chart using a TreeView control. The program’s data structures include Division, Department, and Employee objects. The data validation routines can verify that:

•  Each Employee has a reference to a valid Department.

•  Each Employee’s Department contains a reference to the Employee.

•  Each of a Department’s Employees holds a reference to the Department.

•  Each Department has a reference to a valid Division.

•  Each Department’s Division contains a reference to the Department.

•  Each of a Division’s Departments holds a reference to the Division.

•  Every Division object is contained in the Divisions global collection.

Validate at Startup

A program should run its data validation routines whenever it starts. That guarantees that the routines are run on a regular basis. If the program’s data structures and other components are corrupted, the tests will catch the fact quickly. You can then determine what happened to contaminate the data.

If the data verification routines are fast, you can leave them in the final compiled version of the program. If the data structures are corrupted while end users are using the program, the program should report the fact to you so you can fix it. If you are lucky, you may be able to find the error and fix the data before the users notice the problem.

If the data verification routines are slow, use conditional compilation or a test to see if the program is compiled to run them only in the development environment. You may want to run some of the faster tests in both the development and compiled versions to try to catch some of the more serious errors.

To reduce the impact of the test routines on programmers running the program in the development environment, the tests should occasionally execute the DoEvents statement. That allows the programmer to interact with the user interface while the tests are running. In that case, the programmer must not be able to modify a value or data structure before it has been tested. If the programmer makes a change to the data, it may be inconsistent for a short while and the data validation routines may report an error when none exists.

During design time you can also start the program with a form like the one shown in Figure 5.2. The developer indicates the tests the program should run and clicks the Ok button. The program runs the indicated tests and then continues with its normal functions.

The following code shows one way a program could validate its data before starting normal operation. This is the Load event handler for the program’s main form. ValidationForm is the form shown in Figure 5.2. When the user clicks the Ok button, ValidationForm performs the selected data validations before it unloads itself.

Figure 5.2  A startup test form.

‘ Load and validate the data structures.
Private Sub Form_Load()

    ‘ Load the data structures.
    InitializeData

    ‘ Validate the data structures.
    ValidationForm.Show vbModal
End Sub

Alternatively, you could use the following code to start the program from a Sub Main procedure.

‘ Load and validate the data structures.
Public Sub Main()

    ‘ Load the data structures.
    InitializeData

    ‘ Validate the data structures.
    ValidationForm.Show vbModal

    ‘Display the program’s main form.
    MainForm.Show
End Sub

The main drawback to using a validation form is that developers can circumvent the tests by unchecking all the tests. The tests must be run regularly so they can catch errors as soon as possible. The tests do you no good if no one runs them.